1. Technical Field
The present invention relates generally to a method for delivering a push notification and a push notification server for performing the method and, more particularly, to a method for delivering a push notification and a push notification server for performing the method, which can manage delivery states for respective stages of a procedure in which a push notification message is delivered from a push notification server application to a push notification client application within a user terminal through the push notification server, and can deliver push notifications depending on delivery conditions.
2. Description of the Related Art
With the development of wireless network technology and the popularization of smart devices including smart phones, various types of application programs have appeared, resulting in a significant increase in the usage of wireless resources.
For example, Korean Patent Application Publication No. 10-2013-0108874 entitled “Method and apparatus for implementing an improved notification service for a smart terminal” discloses technology for receiving notification requests from other application servers and a web server, respectively, and effectively processing respective notification request signals through notification service devices corresponding to respective notification requests.
In this way, the number of application programs of a type (hereinafter referred to as an “always-on connection type”) in which each application program is always connected to a network so as to receive a real-time push message (hereinafter referred to as a “push notification”) or the like from the network, as in the case of a messenger service, has rapidly increased recently. The “always-on connection” application programs are problematic in that they are prepared to receive push services while respectively maintaining connections to service providers, thus causing excessively large traffic and rapidly increasing battery power consumption.
In order to solve the above problems, in “Apple” and “Google”, applications in a client maintain connections to push servers through a single daemon. For example, a central push server (for example, Apple Push Notifications (APNs) or Cloud to Device messaging (C2DM)) representatively receives a push message sent from a service provider via an always-on connection. Further, the central push server provides a scheme for sending the push message to the client.
However, the central push server in “Apple” and “Google” does not provide the integrity of push messages. That is, a case where the client cannot receive a push message frequently occurs. In order to provide a push service to clients via the always-on connection, the push server always makes connections to all clients, which will use the push service, and sends push messages to the clients. However, if the network is disconnected before push messages reach the corresponding clients after being attempted to be sent to the clients, the clients cannot receive the push messages. In this case, since the conventional push server does not have a separate management process for allowing the clients to definitely receive the push messages, the reliability of the push messages cannot be guaranteed.
In detail, the push server receives push messages to be sent to clients from an external service provider and sends the push messages to the clients. After sending the push messages, the push server does not perform an additional operation regardless of the results of reception of push messages. That is, even if a client does not normally receive a push message, the conventional push server does not resend a push message or randomly resends a push message without checking a connection to the client.
For example, even in the case of a push message service, such as a KakaoTalk messenger, which is actually operated, there may frequently occur a case where a client does not receive a push message even if the push server sends/resends a push message. As shown in FIG. 1, a conventional commercial push service is problematic in that a case where a push message is not successfully transferred to the client frequently occurs.
In this way, the conventional push server determines that the sending of a push message has failed if the push server does not receive a response message from a client within a predetermined period of time after sending a push message. Further, the conventional push server is problematic in that, when a response is not received from a client, the push server merely recognizes that sending has failed, and does not perform additional handling.